Every unified namespace built in the last several years shares a quiet assumption: humans and applications read from it, and a fairly small, well-understood set of systems write to it. PLCs publish. SCADA and historians subscribe. MES pulls context, ERP gets order status, dashboards render. The topic tree was a broadcast medium. Nobody designed the access model for a piece of software that reads a topic, reasons about it, and then decides to publish a command back.
That assumption is now breaking, plant by plant, as AI copilots and agentic automation move off the pilot slide deck and into systems that touch real topics. The unified namespace (UNS) built on Sparkplug B was the right infrastructure decision for the visibility era. Whether it’s the right infrastructure decision for the agentic era depends entirely on whether you retrofit a permissions model before, not after, an agent gets write access to something it shouldn’t.
Why the UNS looks like the obvious substrate
It’s not a bad instinct. Sparkplug B already gives you a lot of what an AI agent needs: a consistent topic structure (typically following an ISA-95-flavored hierarchy of enterprise/site/area/line/cell), typed metrics with engineering units, birth/death certificates that establish state, and a report-by-exception model that keeps payloads lean. An agent that needs current context for a line — a tag value, a quality metric, a downtime reason code — can subscribe to a well-organized UNS and get exactly what it needs without a point-to-point integration to every PLC or historian.
The trouble starts when the same agent, or a different one in the same pipeline, decides the right move is to publish. Change a setpoint. Acknowledge an alarm. Trigger a changeover sequence. Write a recipe parameter. At that point the UNS stops being a read-only mirror of the plant and becomes an actuation path — and most namespace designs have no topic-level concept of “who is allowed to write here,” let alone “should a non-human actor ever be allowed to write here at all.”
Read-only was never actually enforced — it was just true
Here’s the uncomfortable part: in most existing Sparkplug B deployments, the MQTT broker’s ACLs are set up around edge nodes and applications, not around topic semantics. A broker might restrict which client IDs can publish to a given namespace segment, but it rarely distinguishes between “this is a live sensor value that only the originating edge node should ever write” and “this is a target or setpoint that a supervisory system is allowed to influence.” The separation between read-only telemetry and writable command topics has mostly existed by convention and by the fact that nothing except the PLC’s own edge node was ever trying to publish there.
Bring in an agent — especially one chained into a larger LLM-driven workflow that decides its own next action — and you’ve introduced a publisher that didn’t exist when the topic tree was designed, with intent nobody explicitly authorized. This is the governance gap. It’s not that Sparkplug B is insecure; the STATE mechanism, birth certificates, and MQTT-level TLS and access controls are perfectly serviceable. It’s that nobody drew the line between telemetry space and command space clearly enough for a non-human actor to be trusted near it.
A segmentation pattern that actually holds up
The fix isn’t a new protocol. It’s namespace discipline, applied before you let anything agentic near the broker. A few patterns worth adopting:
- Separate telemetry and command namespaces structurally, not just by naming convention. Instead of relying on topic-name suffixes like /cmd versus /data under the same branch, split them into distinct top-level namespace roots with different ACL groups entirely. It should be structurally impossible for a client with telemetry-subscriber credentials to accidentally have publish rights on a command branch.
- Treat “agent-writable” as an explicit, narrow allowlist, not a default. The default posture for any AI agent should be read-only across the entire UNS. Write access gets granted topic-by-topic, and every grant should map to a specific, reviewable business reason — not “the agent might need it eventually.”
- Use ISA-95 context, not just topic paths, to scope agent permissions. An agent that’s been given equipment and material context via ISA-95 aliasing (line, work center, order, material lot) should have its write scope bounded by that same hierarchy — it can act within the cell it has context for, not laterally across the site. This is where treating the UNS as a semantic layer, not just a transport, actually pays off: permissions can be expressed in terms of equipment hierarchy rather than raw topic strings.
- Distinguish advisory writes from actuating writes. A topic where an agent posts a recommendation, a predicted quality excursion, or a suggested changeover time is fundamentally different from a topic that a PLC or SCADA system treats as an executable setpoint. Keep those in separate namespace branches with separate consumer logic downstream, so a hallucinated or malformed recommendation can never be mistaken for a command by anything actually connected to equipment.
- Log every agent publish with the same rigor as a change-of-state historian record. If an agent writes to the namespace, that event needs an audit trail — who (which model, which version, which prompt or trigger) wrote what, when, and what happened downstream. Most UNS deployments log data changes; far fewer log the identity and provenance of the writer.
A scoping checklist before you grant write access
- Is this topic currently written to only by the originating edge node, and does anything downstream assume that’s still true?
- Does a bad or malformed value on this topic have a path to physical action, or does it stop at a dashboard?
- Can the agent’s write scope be expressed in ISA-95 terms (this line, this cell, this order) rather than as a flat list of MQTT topics?
- Is there a human-in-the-loop gate — an approval step, a rate limit, a bounds check — between the agent’s decision and the write actually landing?
- Can you produce an audit log, after the fact, showing exactly which agent wrote which value to which topic and why?
- What happens on agent failure or a stale MQTT session — does the write default to nothing, or could a dead agent’s last message linger as a retained value?
If you can’t answer most of those today, that’s not a reason to abandon UNS-based agent architectures — it’s a reason to slow the write-access rollout while you keep the read-side moving. Agents that only consume context are low-risk and genuinely useful right now: anomaly summarization, natural-language queries against historian data, contextualized alerting. Agents that publish back into the namespace are a different risk category entirely, and IEC 62443 zone-and-conduit thinking applies to them just as much as it applies to any other actuating system on the network.
What to actually do this year
Don’t wait for a vendor to hand you an “agent-ready UNS” product and assume the permissions model comes free. Audit your existing topic tree for implicit trust — places where “only the PLC writes here” is true only because nothing else has ever tried. Split telemetry and command namespaces at the ACL level, not just the naming level. And insist that any AI agent pilot touching the UNS ships with a documented write-scope, mapped to ISA-95 equipment context, before it goes anywhere near a topic that connects to a setpoint. The UNS made your data accessible. The job now is making sure accessible doesn’t quietly become writable by default.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
